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REMARKS 

The Office Action and cited references have been carefully reviewed. Claims 1-26 
and 30-35 remain pending in this application and are at issue herein. Claims 27-29 were 
withdrawn in a prior office action due to a restriction requirement. Claims 1-26 and 30-35 
are now pending in this application and are at issue herein. 

Claim Objection 

The Examiner has rejected claim 17 because there is an extra "the" within a phrase of 
the claim. The Applicants thank the Examiner for pointing out this typographical error. 
Claim 17 has been amended to correct the error. This correction does not change the scope of 
the claims. The Examiner is respectfully requested to withdraw the claim objection. 

35 U.S.C. §112 Rejections 

The Examiner has rejected claims 1-26 and 30-35 under 35 U.S.C. §112, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the 
subject matter which Applicant regards as the invention. The Examiner has stated that the 
claim language in claims 1, 9, 15, and 21 is not clearly understood. 

With respect to claim 1, the Examiner has stated that it is unclear whether "each 
module" in lines 2 and 6 refers to the "plurality of modules" in line 2 or "at least one selected 
module" in line 1 . The Applicants respectfully disagree. It is respectfully submitted that it is 
clear from reading the claim in its entirety that the phrase "each module" refers to both the 
"at least one selected module" and the "plurality of modules." For example, in line 2, "each 
module" is connected to at least one other module to form the streaming data path. The 
streaming data path comprises the "plurality of modules", which includes the "at least one 
selected module." In line 6, the notification packet is sent to each module within the 
streaming data path. This clearly means that every module in the streaming data path (the 
"plurality of modules" including the "at least one selected module") receives the notification 
packet. 

With respect to claim 9, the Examiner has stated that it is unclear whether "each 
module" and "at least two modules" in lines 1-2 refers to the "plurality of modules" in line 2 
of claim 1 or "at least one selected module" in line 1 of claim 1. The Applicants respectfully 
disagree. It is respectfully submitted that it is clear from reading the claim in its entirety that 
the phrase "each module" refers to both the "at least one selected module" and the "plurality 
of modules" for the same reasons set forth in claim 1 . It is also clear from reading the claim 
in its entirety that the "at least two modules" refers to the "plurality of modules" and not the 
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"at least one selected module" because the "at least two modules" have to be upstream and 
downstream of the "at least one selected module." If the "at least two modules" have to be 
upstream or downstream of "the at least one selected module" as required by the claims, the 
"at least two modules" clearly cannot refer to "at least one selected module." 

With respect to claim 15, the Examiner has stated that it is unclear whether "each 
module" in lines 2 and 6 refers to the "plurality of modules" in line 2 or "at least one selected 
module" in line 1. The Applicants respectfully disagree for the same reasons put forth above 
for claim 1. 

With respect to claim 21, the Examiner has stated that it is unclear whether "each 
module" and "at least two modules" in lines 1-2 refers to the "plurality of modules" in line 2 
of claim 15 or "at least one selected module" in line 1 of claim 15. The Applicants 
respectfully disagree for the same reasons put forth above for claim 9. Additionally, the 
Examiner states that it is unclear why it is necessary to "disconnecting" and "reconnecting" 
each pin of the second module that is being connected to a pin of the first modules in lines 
12-13. It is respectfully submitted that an Applicant is entitled to claim what the Applicant 
believes is its invention. No clarification is believed to be necessary. Claim 21 requires that 
any module (i.e., a second module) other than the module being added (i.e., the first module) 
that does not have an interface to support dynamic reconfiguration and that is going to be 
connected to the first module be stopped and the pins be disconnected from whatever the pins 
were connected to and be reconnected to the pin(s) of the first module. 

In view of the foregoing, it is respectfully requested that the Examiner withdraw the 
35U.S.C. §112 rejection. 

35 U.S.C. §103 Rejections 

To establish a prima facie case of obviousness, there must be some suggestion or 
motivation, either in the references themselves or in the knowledge generally available to 
one skilled in the art, to modify the reference or combine teachings and not based on 
Applicant's disclosure. See MPEP §2142. Any proposed modification cannot render the 
prior art unsatisfactory for its intended purpose or change the principle of operation of a 
reference. There must be a reasonable expectation of success and the prior art references 
must teach or suggest all of the claim limitations. See MPEP §2143. Conclusory 
statements cannot be relied on when dealing with particular combinations of prior art and 
specific claims. The rationale for combining references must be put forth. In re Lee, 61 
U.S.P.Q.2d 1430, 1433. The Examiner can satisfy the burden of showing obviousness of 
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the combination "only by showing some objective teaching in the prior art or that 
knowledge generally available to one of ordinary skill in the art would lead that 
individual to combine the relevant teachings of the references." 

The Examiner has rejected claims 1-4, 7, 13, 15-18, and 25 as being unpatentable over 
Tanigawa (U.S. Patent Number 6,618,368) in view of what the Examiner calls Admitted 
Prior Arts (APA). This ground of rejection is respectfully traversed. Reconsideration of this 
rejection in view of the following comments is respectfully solicited. 

With respect to claim 15, the Examiner states that Tanigawa teaches a method of a 
streaming data path (stream of audio data, column 2 lines 41-53 of Tanigawa) of a graph (Fig. 
15 of Tanigawa) having a plurality of modules (modules 1701, 1705, 1604, 1706, and 1708 
of Fig. 15 of Tanigawa), each module being connected to at least one other module 
(connections of modules in Fig. 15 of Tanigawa) to form the streaming data path (stream of 
audio data, column 2, lines 41-53 of Tanigawa) having at least one input module (module 
1701 of Fig. 15 of Tanigawa) located at an input edge (module 1701 retrieves events 
generated by the user inputs, column 12, lines 59-65 of Tanigawa; module 1706 receives 
notification from 1604, Fig. 15 of Tanigawa) and at least one output module (module 1705 
and 1708 of Fig. 15 of Tanigawa) located at an output edge (module 1705 and 1708 
communicate with controller 204 and output unit 207, Fig. 15 of Tanigawa), the method 
comprising sending a notification packet (audio data relay status, column 12, line 49 of 
Tanigawa) through the streaming data path to each module (relay status notification process 
module 1604 retrieves audio data relay status and informs modules 1706, 1701, 1708 of the 
relay status, column 12, lines 48-52 and Fig. 15 of Tanigawa), detecting when the notification 
packet is received at each output module (monitoring is performed to see if relay status 
notifications have been received, column 14, line 67 to column 15, line 1 of Tanigawa). The 
Examiner then states that Tanigawa does not explicitly teach adding a module and that what 
the Examiner calls APA teaches in existing systems, anytime there is a need for changing to 
the processing elements within a stream, all of the modules connected together are stopped, 
add a module, and the modules are restarted and that it would have been obvious to apply the 
teachings of Tanigawa because the added modules would provide additional control to the 
system. 

The Applicants agree that Tanigawa does not teach adding a module to a streaming 
data graph. Tanigawa teaches an audio gateway that performs relay operations on the audio 
data to direct the audio streams to the destination such as a telephone. The modules of Fig. 
15 are the components that make up a communication management module of a control 
device. It is respectfully submitted that adding any module to the communication 
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management module requires the control unit to shut down completely and cannot be 
changed dynamically. Changing the communication module while multiple audio data 
streams are running would not be successful and would render the control unit unsatisfactory 
for its intended purpose. 

The prior systems to which the Examiner refers requires that all the modules in the 
streaming data path are stopped. Claim 15 is a method to dynamically add a module to a 
streaming data path. This means that, unlike prior systems, the modules within the streaming 
data path do not have to be stopped to add the module to the path. Data flow to modules 
within an area of the graph being changed is stopped, but modules that support dynamic 
reconfiguration continue to operate. Neither Tanigawa nor what the Examiner calls APA 
teaches or suggests dynamically adding a module to a streaming data path of a graph. 

Claim 15 requires that the notification packet indicate that data flow has stopped. The 
Examiner properly stated that the packet of Tanigawa is an audio data relay status that 
provides status of the relay. It is respectfully submitted that a packet that provides relay 
status does not provide any indication that data flow has stopped. 

Claim 15 also requires detecting when the notification packet is received at each 
output. Column 14, line 67 to column 15, line 1 of Tanigawa teaches monitoring to see if 
status notifications have been received from gateways. These status notifications are inputs 
from gateways and are not output modules as required by claim 15. 

Furthermore, the Examiner's stated reason for combining Tanigawa and what the 
Examiner calls APA could not be found or suggested in Tanigawa or what the Examiner calls 
APA. It is well known that the mere fact that references can be combined or modified does 
not render the resultant combination obvious unless the prior art also suggest the desirability 
of the combination. See MPEP 2143.01 . It is respectfully submitted that the Examiner's 
statement for combining references is a conclusory statement that is prohibited. 

Therefore, neither Tanigawa nor what the Examiner calls APA, singly or in 
combination, teach or suggest all of the limitations of claim 15. In view of the foregoing, it 
is respectfully requested that the Examiner withdraw the rejection of claim 15. 

Claims 16-18 and 25 depend from claim 15 and are believed to be patentable for the 
same reasons put forth above for claim 15. 

With respect to claim 16, the Examiner states that what the Examiner calls APA 
teaches acquiring a graph lock and points to page 2, lines 19-21 of the specification for 
support. As explained in the application at page 16, lines 17-21, the purpose of the graph 
lock is to avoid inconsistent graph states while a change is being made so that other changes 
can't be made at the same time. Acquiring a graph lock prevents other changes from being 



14 



In re Appln. of Syon Bhattacharya et al. 
Application No. 09/629,234 

made to the graph. It does not mean that the modules in the graph are stopped. Lines 19-22 

on page 2 of the application states: 

"In existing systems, any time such a change is made to 
the processing elements, all of the modules connected together 
are stopped, the required changes made, and the modules are 
restarted. In many instances, modules flush the data being 
processed, resulting in a significant amount of data loss and 
delay in streaming processing." 

Stopping all of the modules of a graph means that all modules in the graph must be stopped. 

No teaching or suggestion of acquiring a graph lock could be found. It is respectfully 

submitted that the Examiner is using the instant application as a roadmap and reading the 

teachings of the present application into the prior art where no teaching or suggestion exists, 

which is prohibited by the MPEP. 

With respect to claim 17, the Examiner states that what the Examiner calls APA 
teaches executing a multiple wait and points to page 2, lines 19-21 of the specification for 
support. As explained in the specification on page 16, line 22 to page 17, line 4, a deadlock 
can occur when an application has commanded the streaming data graph to stop and a module 
initiating a change is waiting for the graph lock. To avoid this deadlock, the module 
initiating the change executes a multiple wait that specified that the wait exits if either the 
graph lock or an event object is set. The event object is signaled with the module is asked to 
stop processing data, which triggers any wait that is executing, such as the multiple wait, so 
that processing can stop in an orderly way. No teaching or suggestion of executing a multiple 
wait could be found. It is respectfully submitted that the Examiner is using the instant 
application as a roadmap and reading the teachings of the present application into the prior art 
where no teaching or suggestion exists, which is prohibited by the MPEP. 

With respect to claim 18, the Examiner states that what the Examiner calls APA does 
not explicitly teach removing a module, but that it teaches that there are times when a 
particular module needs to be changed such as a different decoding module is required and 
refers to page 2, lines 13-15 of the specification. The Examiner then states that one of 
ordinary skill in the art would conclude that in this case, the particular module mentioned 
above needs to be removed in order for the stream to add a different decoding module and 
that therefore, it allows the stream to adapt to the new environment by simply removing the 
unnecessary module. MPEP 2143.01 specifically states that the fact that a claimed invention 
is within the capabilities of one of ordinary skill in the art is not sufficient by itself to 
establish prima facie obviousness and that the level of skill in the art cannot be relied upon to 
provide the suggestion to combine references. It is respectfully submitted that the Examiner 
has failed to put forth a prima facie case of obviousness. 
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In view of the foregoing, it is respectfully requested that the Examiner remove the 
rejection of claims 15-18. 

With respect to claim 25, the Examiner has rejected claim 25 for the same reasons as 
claim 15. Claim 25 is believed to be patentable for the same reasons as claim 15. It is 
respectfully requested that the Examiner remove the rejection of claim 25. 

With respect to claim 1, the Examiner states that claim 1 is a method claim of claims 
15 and 18 and has rejected claim 1 for the same reasons as claims 15 and 18. Claim 1 is 
directed to a method of dynamically removing at least one selected module and claim 15 is 
directed to a method of dynamically adding at least one selected module. Therefore, claim 1 
cannot be a method claim of claims 15 and 18. However, claim 1 does have claim limitations 
that are the same as claims 15 and 18. Therefore, claim 1 is believed to be patentable for the 
same reasons as claims 15 and 18. Furthermore, neither Tanigawa nor what the Examiner 
calls APA teach or suggest dynamically adding a module after detecting when the 
notification packet is received at each output module. Therefore, it is respectfully requested 
that the Examiner withdraw the rejection of claim L 

Claims 2-4 and 7 depend from claim 1 and are believed to be patentable for the same 
reasons as claim 1. With respect to claims 2 and 3, the Examiner states that they are method 
claims of claims 16-17 and are rejected for the same reasons as claims 16 and 17. Claims 2-3 
are also believed to be patentable for the same reasons as claims 16 and 17. 

With respect to claim 4, the Examiner states it is a method claim of claim 15 and is 
rejected for the same reasons as claim 15 above. Claim 4 does have claim limitations that are 
similar to limitations of claim 15. Claim 4 is also believed to be patentable for the same 
reasons set forth above for claim 15. 

With respect to claim 7, the Examiner states that it is a method claim of claims 15 and 
19 and is rejected for the same reasons as claims 15 and 1 9. It is respectfully submitted that 
claim 19 has not been rejected over Tanigawa and what the Examiner calls APA. Therefore 
the Examiner is respectfully requested to withdraw the rejection of claim 7 and for the 
reasons below with respect to claim 19, which the Examiner has rejected for different 
reasons. 

With respect to claim 13, the Examiner states that it is a computer readable medium 
claim of claim 1 and is rejected for the same reasons as claim 1 above. Claim 13 is believed 
to be patentable for the same reasons put forth above for claim 1. 

In view of the foregoing, it is respectfully requested that the Examiner withdraw the 
rejection of claims 2-4, 7, and 13. 
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The Examiner has rejected claims 5-6, 8-12, 14, 19-24, 26, and 30-35 as being 
unpatentable over Tanigawa (U.S. Patent Number 6,618,368) in view of what the Examiner 
calls APA and further in view of Krause (U.S. Patent Number 5,815,707). This ground of 
rejection is respectfully traversed. Reconsideration of this rejection in view of the following 
comments is respectfully solicited. 

Claims 19-24 depend from claim 15 and are believed to be patentable for the same 
reasons put forth above for claim 15. With respect to claim 19, the Examiner properly states that 
Tanigawa as modified does not explicitly teach that each module has at least one pin. The 
Examiner then states that Kraus teaches a streaming data system (Fig. 3 of Krause) wherein each 
streaming module (modules 17, 14, and 30 of Fig. 3 of Krause) has two pins (write and read 
queues, Fig. 3 of Krause) that connect the modules together. The Examiner then states it would 
be obvious to apply the teachings of Krause to the system of Tanigawa because whenever a new 
module needs to be added into the stream, the pins within the new module would be used to 
connect the new module with the other modules of the stream and thereby the new module 
would use the pins to communicate with other modules of the stream. 

As explained in the present application, the stream architecture utilizes an interconnected 
organization of filters, and employs the mechanism of "pins" to communicate to and from the 
filters, and to pass data. Both filters and pins are Component Object Model (COM) objects. 
The filter is a COM object that performs a specific task, such as transforming data, while a pin is 
a COM object created by the filter to represent a point of connection for a unidirectional data 
stream on the filter. Input pins accept data into the filter while output pins provide data to other 
filters. Filters and pins preferably expose control interfaces that other pins, filters, or 
applications can use to configure the behavior of those filters and pins. Krause has been 
thoroughly reviewed and no teaching or suggestion could be found of a pin or disconnecting the 
pin for each module to be connected to the first module and connecting the pin to a pin of the 
first module. Therefore, neither Tanigawa, what the Examiner calls APA, nor Krause, singly or 
in combination, teach or suggest the claim limitations of claim 19. 

With respect to claim 20, the Examiner states that it is a method claim of claims 15 and 
19 and is rejected for the same reasons as claims 15 and 19. Claim 20 is believed to be 
patentable for the same reasons as put forth above for claims 15 and 19. 

With respect to claim 21, the Examiner states that Krause teaches that each module 
(modules 17, 14 and 30 of Fig. 3 of Krause) has at least one pin (write and read queues of the 
modules of Fig. 3 of Krause), at least two modules (17 and 14 of Fig. 3 of Krause) have at 
least one interface (stream head consists of a set of routines that provide the interface 
between applications in user space and the rest of the stream in kernel space, column 1, lines 
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65-67 of Krause) to support dynamic reconfiguration (intermediate processing element that 
can be dynamically added to, column 2, lines 41-42 of Krause), one (17, Fig. 3 of Krause) of 
the two modules being upstream (module 17 of Krause is head of the stream that receives 
user input, column 2, lines 1-2 of Krause) of the first module (30, Fig. 3 of Krause) and the 
other (14, Fig. 3 of Krause) of the two modules being downstream (end or tail of the stream, 
column 2, line 10 of Krause) of the first module comprising locating at least one input edge 
module (module 17 of Krause) being one of the at least two modules that is upstream of the 
first module; locating at least one output edge module (module 14 of Fig. 23 of Krause) being 
the other of the two modules that is downstream of the first module. The Examiner then 
states that the concept of adding or removing a module as was as if there is a need for 
changing to the processing elements within a stream, all of the modules connected together 
are stopped, make the changes and restarted is clearly discussed within claim 15 and 18 as 
taught by Tanigawa and what the Examiner calls APA. The Examiner also states that Krause 
teaches pins within a module. The Examiner then states that one of ordinary skill in the art 
would conclude that by adding or removing a module, the first thing that is needed to be done 
is disconnect the pins of an existing module within the stream chain, then reconnect those 
pins of a new module (or in the case of removing a module, disconnect the pins of an existing 
module within the stream chain, remove that module and the reconnect pins of the modules 
that stay). 

It is respectfully submitted that the Examiner's stated reasons for rejecting claim 21 is 
a conclusory statement that is prohibited by the MPEP (see MPEP 2144.03) and in re Lee. 
Furthermore, no teaching or suggestion could be found in Tanigawa, what the Examiner calls 
APA or Krause, singly or in combination, of accounting for legacy modules that do not 
support dynamic reconfiguration (i.e., adding and/or removing modules) by commanding of 
second modules (e.g., a legacy module) that are between modules that support dynamic 
reconfiguration that will be connected to a module that is being added to stop, pins of each 
second module to be connected to the added module be disconnected from what the pins are 
connected to and reconnect the pins to the added module as required by claim 21 . 

With respect to claim 22, the Examiner states that claim 22 is rejected for the same 
reasons as put forth for claim 21 . Claim 22 is believed to be patentable for the same reasons 
set forth above with respect to claim 21. Additionally, no teaching or suggestion could be 
found in Tanigawa, what the Examiner calls APA or Krause, singly or in combination, of 
removing a selected module that is to be removed by commanding the selected module to 
change to a stop state, disconnecting each pin that is connected to the selected module, and 
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reconnecting each pin that was connected to the selected module to a pin of another module 
that was connected to the selected module. 

With respect to claim 23, the Examiner states it is a method claim of claims 15 and 21 
and is rejected for the same reasons as claims 15 and 21. Claim 23 is believed to be 
patentable for the same reasons as claims 15 and 21. 

With respect to claim 24, the Examiner states it is a method claim of claim 16 and is 
rejected for the same reasons as claims 16. Claim 24 is believed to be patentable for the same 
reasons as claim 16. 

With respect to claim 26, the Examiner states it is a computer readable claim of claim 
21 and is rejected for the same reasons as claim 21. Claim 26 is believed to be patentable for 
the same reasons as claim 21. 

With respect to claim 33, the Examiner states that Krause further teaches each module 
provides an interface (each component's queue provides an interface between the component 
and the rest of stream, column 2, lines 40-41 of Krause) comprising a command to determine 
if an input pin of a processing module can accept a media type on a next data sample (one of 
the ioctl commands is use to alter active instances of a module, column 9, lines 62-66 of 
Krause). The Examiner also states that Tanigawa further teaches a command to provide 
notice (notifies appropriate processing modules, column 12, lines 63-64 of Tanigawa) and a 
command to signal when a reconnection should end (terminates the connection when a 
communication release notification is received, column 7, lines 16-16 of Tanigawa). 

Column 9, lines 62-66 of Krause teaches that two new commands are used to alternate 
dynamically streamtabs of a Streams module/driver. One of the ioctl commands is use to 
alter active instance of a module. Krause teaches that the ioctl command is used to alter qinit 
routines for the instance. The routines are listed in alt index field of the command and are 
shown in column 10, line 50 to column 11, line 5. None of the routines is a command to 
determine if an input pin of a processing module can accept a media type on a next data 
sample. No teaching or suggestion could be found in Tanigawa, what the Examiner calls 
APA, or Krause of a command to determine if an input pin of a processing module can accept 
a media type on a next data sample. Additionally, Tanigawa at column 12, lines 63-63 
teaches that appropriate processing modules are notified base on the nature of an event. The 
event is an input command. A notification based on the nature of an input command is not a 
command that provides notice when the processing module has processed data. Furthermore, 
the present application teaches at page 17, lines 18-19 that the IsEndPin command signals 
that, by default, reconnection searches should end at this input pin. It is respectfully 
submitted that terminating a connection when a communication release notification is 
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received does not teach or suggest a command to signal when a reconnection should end at 
the input pin. Furthermore, the Examiner has not put forth any statement as to why a person 
skilled in the art would combine the "commands" of Tanigawa, what the Examiner calls 
APA, and Krause, which is required by the MPEP. Therefore, it is respectfully submitted 
that the Examiner has not put forth a prima facie case of obviousness. 

With respect to claim 34, the Examiner states that Krause teaches each module 
provides an interface (each component's queue provides an interface between the component 
and the rest of stream, column 2, lines 40-41 of Krause) and that what the Examiner calls 
APA teaches a command to temporarily block data flow (command issued that made all of 
the modules within the stream stopped and refers to page 2, lines 19-20). The Examiner has 
not put forth any statement as to why a person skilled in the art would combine the 
"commands" of Tanigawa, what the Examiner calls APA, and Krause, which is required by 
the MPEP. Furthermore, page 2, lines 19-20 of the present application teaches that in prior 
systems, all of the modules connected in a graph are stopped. This means that all modules in 
the graph must be stopped. No teaching or suggestion of temporarily blocking data flow 
from an output pin of a processing module could be found in any of the cited references or 
what the Examiner calls APA. It is respectfully submitted that the Examiner is using the 
instant application as a roadmap and reading the teachings of the present application into the 
prior art where no teaching or suggestion exists, which is prohibited by the MPEP. 
Therefore, it is respectfully submitted that the Examiner has not put forth a prima facie case 
of obviousness. 

With respect to claim 35, the Examiner states that Krause teaches each module 
provides an interface (each component's queue provides an interface between the component 
and the rest of stream, column 2, lines 40-41 of Krause) comprising a command to perform a 
dynamic reconnection (dynamic function replacement, column 4, lines 30-31 of Krause) 
between an output pin and input pin (write and read queues of Fig. 3 of Krause); a command 
to put a module into a cache (cache miss, column 4, line 14 of Krause); a command to 
remove a module (remove intermediate processing elements, column 1, lines 32-33); a 
command to enumerate modules (examine a particular stream instance, column 5, lines 
51-52 of Krause); a command to get a start time (time stamping, column 14, line 23 of 
Krause); a command to push data to a pin (modules can be pushed onto pipes to obtain 
more functionality, column 3, lines 17-18 of Krause). 

It is respectfully submitted that the Examiner has read Krause out of context. The 
dynamic function replacement of Krause as explained on column 4, lines 36-40 is a 
mechanism for "replacing these function definitions and, hence, changing the execution 
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behavior of STREAMS modules and drivers without requiring the modules or drivers to 
be rewritten or modified. Replacing a function without requiring modules or drivers to be 
rewrilten or modified not only does not teach or suggest performing a dynamic 
recbnnection between an output pin and an input pin, it suggests that no reconnection 
need be performed. As such, it teaches away from performing a dynamic reconnection 
between an output pin and an input pin. 

Furthermore, Krause teaches that a cache miss refers to a variable that is not in the 
system's cache. It does not teach a command to put a module into a cache as suggested 
by the Examiner. As for the command to remove a module from a cache, no teaching or 
suggestion could be found in Krause, Tanigawa, or what the Examiner calls APA that 
modules are removed from a cache. As for the command to enumerate modules, Krause 
teaches that to examine a particular STREAMS instance, such as a connection between 
two systems, is not possible without writing complex code for the driver or module to 
respond for a particular instance. This means that Krause does not teach or suggest a 
command to enumerate modules in the cache. No teaching or suggestion of enumerating 
modules in the cache could be found in Tanigawa or what the Examiner calls APA. As 
for the command to get a start time used when a graph run call was last commanded, no 
teaching or suggestion in Krause, Tanigawa, or what the Examiner calls APA could be 
found of a graph run call. Therefore, none of the references or what the Examiner calls 
APA teaches or suggests a command to get a start time used when a graph run call was 
last commanded. As for a command to push data to a pin, column 3, lines 1 7- 1 8 of 
Krause teaches that operations that can be applied to a stream can be applied to a pipe and 
that modules can be pushed onto pipes. Pushing an operation or a module onto a pipe 
does not teach or suggest pushing data to a specified pin. Therefore, neither Krause, 
Tanigawa, nor what the Examiner calls APA teaches or suggests all of the elements of 
claim 35. 

With respect to claims 5-6, the Examiner states the claims are method claims of claim 
19-20 and are rejected for the same reasons as claims 19-20 above. Claims 5-6 are believed 
to be patentable for the same reasons as claims 19-20. 

With respect to claim 8, the Examiner states that Krause further teaches moving each 
selected module into a filter graph cache and refers to column 4, line 14 of Krause. As 
previously explained, Krause teaches that a cache miss refers to a variable that is not in the 
system's cache. It does not teach a command to move each selected module into a filter 
graph cache as suggested by the Examiner. 
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i With respect to claims 9-10, the Examiner states that these claims are method claims 
of claim 21 and are rejected for the same reasons as claims 21. Claims 9-10 are believed to 
be patentable for the same reasons as claim 21 . Additionally, claim 21 does not contain all of 
the elements of claim 10. However, claim 10 is similar to claim 4 and is believed to be 
patentable for the same reasons as claim 4. 

With respect to claims 11-12, the Examiner states the claims are method claims of 
claims 23-24 and are rejected for the same reasons as claims 23-24 above. Claims 11-12 are 
believed to be patentable for the same reasons as claims 23-24. 

With respect to claim 14, the Examiner states the claim is a computer readable 
medium claim of claim 9 and is rejected for the same reasons as claim 9 above. Claim 14 is 
believed to be patentable for the same reasons as claims 9. 

With respect to claims 30-32, the Examiner states the claims are method claims of 
claims 33-35 and are rejected for the same reasons as claims 33-35 above. Claims 30-32 are 
believed to be patentable for the same reasons as claims 33-35. 

In view of the foregoing, it is respectfully requested that the Examiner withdraw the 
rejection of claims 5-6, 8-12, 14, 19-24, 26, and 30-35. 



The application is considered in good and proper form for allowance, and the 
Examiner is respectfully requested to pass this application to issue. If, in the opinion of the 
Examiner, a telephone conference would expedite the prosecution of the subject application, 
the Examiner is invited to call the undersigned attorney. 



Conclusion 



Respectfully submitted, 




Kevin L. Wingate, Reg. N^?5S662 
LEYDIG, VOIT & MAYER, LTD. 
6815 Weaver Road, Suite 300 
Rockford, Illinois 61 1 14-8018 
(815) 963-7661 (telephone) 
(815) 963-7664 (facsimile) 



Date: June 24, 2004 
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